Introduction to API Security

Introduction#

With the popularity and usage of APIs growing exponentially each year, API exploitations have become a key attack vector for nefarious actors. An API doesn't function in isolation but is designed to be used in tandem with other applications (for example, the Google API communicates with the Facebook API to incorporate sign-in). Therefore, an insecure API won't only lead to the vulnerability of our data but also puts the sensitive data of other applications at risk. So implementing security protocols becomes an utmost priority in API design.

We need application security (both client and server side) and data security (both at rest and in transit). Therefore, API security becomes a combination of all these security methods plus network security:

Let's suppose we have an API like Spotify, which uses our Google account to log in. What are the protocols and procedures we should follow to make sure our sign-in information isn't intercepted or tampered with by a third party? Why do we use Google to sign in to our Spotify account? What level of information should be shared between the application to authenticate the user? To answer these questions, we'll focus on the security aspects of API design through elements, such as authentication, authorization, encryption, access control, etc., to protect not only the data in our APIs but also the data it's accessing and transferring.

As time goes on, the number of digital attack surfaces are increasing. There are numerous methods through which malicious users may attack, the primary methods being as follows:

• Distributed denial of service: This is when multiple machines target a specific entity in our system by overloading it with requests to disrupt its regular functioning. The attack traffic in this method is usually in the form of a botnet.

• Insufficient authentication: When our clients aren't adequately authenticated (the procedure through which our API verifies who the user is), our API may receive bogus or potentially malicious calls that may hinder its functionality and lead to issues in access control.

• Injections: When malicious code is entered into our system, it endangers the data present in our API along with access control. This is most commonly done through cross-site scripting (XSS) or SQL injections, which we’ll expand on in an upcoming lesson.

• Exposed data in API calls: When transferring data, an attacker may intercept the data and impersonate one of the parties, which is known as the man-in-the-middle attack. This can lead to the impersonator gaining unauthorized access to our data, which could lead to devastating consequences.

The diagram below illustrates the surfaces where these attacks may occur from:

It's important to clarify that there's no such thing as a perfectly secure API; therefore, our APIs also have to be scalable in order to implement new security mechanisms. To begin understanding the common security protocols, we first have to understand the process in which API security is handled.

The process of API security#

If you're well-versed in the API landscape, it should come as no shock that security is often overlooked. Developers are constantly adopting new security mechanisms related to API practices, but there will always be vulnerabilities for attackers to uncover. It's much easier and resource effective to consider security at the inception of the API's design and scale it as time goes on rather than retrofitting to an already finished API later in its lifecycle. There are many aspects that should be contemplated when designing a secure API, namely the ones mentioned in the illustration below:

Assets#

Assets are considered to be the sensitive data and entities that need to be protected. This may include physical devices that our API depends on, such as application and caching servers, databases, or digital entities (the data stored in our API). Physical assets are easy enough to guard with the use of security cameras and whatnot, but protecting our virtual data from harm is a different fight altogether. The inability to protect these assets could lead to reputational and financial damage. So, we define some goals to prevent such situations.

Security goals#

Our primary security goal should be the protection of these assets, most commonly defined through the CIA triad. The CIA triad is a general security model that has been employed for decades. This triad is represented by three components that lay the groundwork for our design principles and implementations.

The three factors are as follows:

• Confidentiality: This refers to the guidelines and regulations administered that make sure that only authenticated users have access to relevant information. Enabling secrecy and privacy serves as the primary goal of confidentiality.

• Integrity: This aspect ensures that the information present is accurate and reliable and not tampered with in any way, whether it be intentional alteration by attackers or data corruption in transmission.

• Availability: This feature guarantees that the users we have validated have a constant entry point to the data they wish to access. More plainly, it refers to our servers, machines, and applications being in a constant state of functioning, so our authorized users can access our resources in a convenient manner.

Note: Although the principles above are the most celebrated, other goals such as accountability and non-repudiation can be helpful in other contexts.

Threat modeling#

It's imperative that we define the threats faced by our API in the environment in which we run it. As with any entity that allows public access to its resources, it provides an attack surface for malicious actors to exploit. These attack surfaces only increase as the usage of API becomes commonplace, leading many to speculate that API attacks may become the most relevant attack vector in the future.

The set of threats relevant to our API is defined as our threat model, which can be classified through the STRIDE acronym, which is expanded on in the table below:

The process of threat modeling is as follows:

1. Curate a system diagram highlighting the primary entities (such as clients and endpoints) in our API, and pinpoint the trust boundaries of each component.

2. Identify information flow between the system entities, and model it as directed arrows.

3. For each trust boundary drawn in the prior steps, map out potential threats to our security goals, perhaps by referring to the STRIDE model.

4. Select mechanisms that aid us in achieving our security goals to combat threats defined in the STRIDE model. We record these threats to guarantee that they are kept track of in the development lifecycle.

An example of a threat modeling diagram is given below:

Note: The API and database have separate trust boundaries to avoid the risk of a compromised API accessing sensitive information present in the database.

Depending on the nature of the API, we may decide to concentrate our efforts on a specific aspect of security. For example, if our API exclusively handles sensitive user data, we need to emphasize security measures that protect this information. On the other hand, if the data isn't sensitive and can be accessed publicly, the same measures aren’t required to protect the data. Through threat modeling, we aim to uncover gaps in our system and in turn, bolster our defenses against these threats by utilizing security mechanisms that deal with a particular security need.

Mechanisms#

Now that we've mapped out the threats with the modeling mentioned above, we require sufficient means to secure our APIs. To guard against these attacks, we have to implement security mechanisms that can be found in any well-developed API.

To guarantee that a certain security goal is met, we apply the following mechanisms, among others:

• Encryption: While most mechanisms protect access to the API itself, encryption secures data whilst it's transmitted over the network between applications. This mechanism fulfills the confidentiality aspect of the triad so that even if the data is intercepted, it'll be useless to unauthorized users without the correct decryption methods. Primarily in API design, TLS is used to secure the transfer of data over networks. It aids in integrity and confidentiality.

• Validation: This is the process through which we verify the data entering the API itself. It's an essential aspect that prevents tampering and information disclosure and should be implemented in every API. It aids in confidentiality.

• Authentication: Through authentication, we can verify whether an actor is authorized. When implemented correctly, it nullifies the spoofing and elevation of a privilege threat in which users pretend to be somebody they're not. It aids in confidentiality.

• Authorization: This aspect serves to protect both the identity and confidentiality of our clients, as stated in the CIA triad. This strives to strengthen access control, through which threats such as tampering should be rendered obsolete.

We'll study these topics in finer detail over the course of this chapter.

Chapter roadmap#

Our goal in this chapter is to understand different techniques that will allow us to design secure APIs. For this purpose, we’ll dive deep into the mechanisms that enable us to secure the communication not only between client and server but also between different microservices of a larger service. Our chapter is mapped out in the diagram below:

We'll divide the major concepts of security into four sections, each of which helps us implement the triad in our own API:

• We'll look into encryption and validation, including how to safely transmit data between entities and the subsequent validation.

• We'll delve into cross-origin resource sharing (sharing resources between different hosts), its vulnerabilities, and how to overcome them.

• It’s essential to build knowledge on how systems verify their users and designate permissions on what they're allowed to view and access. Our goal is to describe various protocols and techniques on how authentication and authorization are performed in API designing.

• We'll close the chapter by discussing security models and the scope of APIs. We’ll also take a quiz to test ourselves on these concepts.

All in all, API security is a complex mesh of processes, mechanisms, threats, and demands. Attackers will continue to find new ways to specifically target APIs. The process of implementing API security is slow, with vulnerable code commonly being launched to meet deadlines. Therefore, API security is essential, especially in today's day and age.

Let's explore how the transmission of data is secured in the upcoming lesson.